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Constraints that may be obtained by composition from simpler constraints 
are present, in some way or another, in almost every constraint program. The 
decomposition of such constraints is a standard technique for obtaining an 
adequate propagation algorithm from a combination of propagators designed 
for simpler constraints. The decomposition approach is appealing in several 
ways. Firstly because creating a specific propagator for every constraint is 
clearly infeasible since the number of constraints is infinite. Secondly, be- 
cause designing a propagation algorithm for complex constraints can be very 
challenging. Finally, reusing existing propagators allows to reduce the size of 
code to be developed and maintained. Traditionally, constraint solvers auto- 
matically decompose constraints into simpler ones using additional auxiliary 
variables and propagators, or expect the users to perform such decomposi- 
tion themselves, eventually leading to the same propagation model. In this 
paper we explore views, an alternative way to create efficient propagators 
for such constraints in a modular, simple and correct way, which avoids the 
introduction of auxiliary variables and propagators. 

1 Introduction 

Most specialized filtering algorithms, i.e. propagators, available in constraint solvers 
target constraints with a specific algebraic structure. When the problem to be solved 
has a constraint for which no propagator exists one option is to decompose it into some 
logically equivalent formula involving simpler constraints. This can be done either by the 
user, or automatically if the solver supports it, by introducing a set of auxiliary variables 
and propagators. In practice the constraints which are most often decomposed are those 
involving multiple distinct arithmetic or logical expressions. Throughout this paper we 
will refer to constraints for which no specialized filtering algorithm is appropriate, and 
which are therefore considered for decomposition, as decomposable constraints. 

In this paper we describe view-based propagation - a method for propagating decom- 
posable constraints that avoids the use of auxiliary variables and propagators. Although 
this method does not improve the strength of the propagation algorithm, it results in 
significantly faster propagation compared with the decompositions obtained with aux- 
iliary variables for the specific class of bounds completeness. An important aspect of 
view based propagation is that it does not preclude the introduction of auxiliary vari- 
ables when required, meaning it can be combined with other modeling techniques such as 
subexpression substitution or variable elimination. It can also be used with specialized 
propagation algorithms, e.g. used in global constraints (or even replace them), allow- 
ing the exploitation of the decomposition approach combined with the efficiency of such 
dedicated algorithms. 

The problem of propagating decomposable constraints may be approached using knowl- 
edge compilation techniques [15, 7]. These methods create a compact tractable represen- 
tation of the set of solutions to the constraint and apply a general propagation algorithm 
which filters tuples not found in this set. However, due to its expensive runtime complex- 
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ity applying these methods with arithmetic expressions is only practical when expressions 
have small domains. In contrast, view-based propagators for decomposable constraints, 
extending previous proposals for propagators (e.g. indexical constraints [17, 6]), do not 
require exponential memory. 

Rina Dechter [22] approaches decomposition of constraints from a different perspec- 
tive. There, the full constraint network is taken into consideration in order to obtain 
generic global search algorithms with theoretical performance guarantees. The propa- 
gation is still time or space exponential but depends exclusively on specific graph-based 
parameters of the graph describing the constraint network. In contrast, we focus on the 
decomposition of a single constraint into simpler constraints for which local propagation 
algorithms are applied independently. 

View based-propagation was introduced in [10] and [24]. The former presents a general 
overview of a constraint solver incorporating type polymorphism and its application for 
creating propagators from decomposable expressions. The latter coins the term view (we 
originally called them polymorphic constraints), and describes how it can be used for 
creating generic propagator implementations, that is, propagators which can be reused 
for different constraints. The present work can be seen as an extension of [26, 25] for 
allowing the use of a particular kind of view over functions involving multiple variables 
([26] restricts the use of views to injective functions and therefore to unary functions 
mostly). We adapted and extended its formalization to present and prove important 
properties of our model. Additionally, our framework employs views as modeling primi- 
tives by automatically deriving new propagators for decomposable constraints present in 
a problem. In contrast, views as described in [26] are used essentially as a development 
tool for increasing the number of available propagators in the library. 

Compilers for constraint modeling languages [21, 11, 1] generate efficient constraint 
solvers from a high level description of a constraint problem. The solver generation 
process may avoid introducing auxiliary variables for a decomposable constraint whenever 
a specific propagator is available. In this paper we will show that, in the absence of a 
specific propagator for a given constraint, a view-based propagator may be an appealing 
alternative. 

Indexicals [17, 6] and constrained expressions [18] are conceptually close to the idea of 
views described in this paper. Like views, these techniques intend to support automatic 
propagation of decomposable constraints, however they require extra work from the user 
(in the case of indexicals) or the CPU (in the case of constrained expressions) when 
compared to our approach, These (dis)similarities will be discussed after the necessary 
background is presented. 

This paper is organised as follows. The following section overviews the main concepts 
of constraint programming, introducing domains and domain approximations as well as 
constraint propagators and their main properties. Section 3 presents some examples of 
decomposable constraints and how to express propagators for such constraints, discussing 
the properties of various approximations, namely soundness and completeness. It also 
introduces box view propagators, the propagation model that will be used throughout the 
paper. Section 4 briefly addresses two alternatives for implementing box views in strongly 
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typed programming languages (exploiting either subtype or parametric polymorphism). 
Section 5 presents experimental results for a comprehensive set of benchmarks. The paper 
concludes in section 6 with a summary of the results obtained and some suggestions for 
future work. 
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2 Background: Domains and Propagators 

This section presents the necessary concepts and notation for describing propagation in 
detail. 

2.1 Constraint Satisfaction Problems 

A constraint satisfaction problem (CSP) is a triple (X, D, C) where X is a finite set of 
variables, D is a finite set of variable domains, and C is a finite set of constraints. We 
refer to the set of constraints involving some variable x £ X as C (x) and the set of 
variables in some constraint c £ C as X (c). 

An n-ary constraint (on variables set of tuples on its n variables (n- 

tuples). Although tuples of integers will be most often used, we only expect that the 
elements in a tuple are from totally ordered types. In general, we will denote an n-tuple 
as x ra and a set of n-tuples as S n (or simply x and S respectively when there is no 
ambiguity on its arity) and the set of tuples of constraint c as con (c). 

Implicitly, a constraint restricts the values of each of its variables. Denoting by 
projj (S n ) or simply Sf the projection of the set of tuples to their i-th element, con- 
straint c restricts its i-th variable to take values in con(c)j. In particular, the variable 
domain constraint D (x) is a special case of a unary constraint, restricting the initial 
values of variable x. 

2.2 Domain Approximations 

Following [26] we generalise the notion of domains from single variables to more general 
n-ary domains and characterize their approximations. First we denote by conv the 
convex hull of some set S 1 from an ordered type T> i.e. 

convx> (S 1 ) = {z :mm(S r ) < z <max(S 1 )} 

We introduce now important tuple set operations: Cartesian approximation (see for 
example [2]) and box approximation [4]. 

Definition 2.1 (Cartesian approximation). The Cartesian approximation S s (or 6- 
approximation) of a tuple set S C Z n is the smallest Cartesian product which contains 
S, that is: 

S 5 = proj 1 OS)x...xproj n (S) 

Definition 2.2 (Box approximation). The box approximation (or /3-approximation) 

of a tuple set S C V n is the smallest n-dimensional box containing S, that is: 

= conv© (proj! (S)) x . . . x conv© (proj n (S)) 

We will address integer and real box approximations, i.e. or SPW, and denote 

these box approximations by S 13 and S p , respectively. Additionally, we will use the 
identity approximation in order to simplify notation. 
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Definition 2.3 (Identity approximation). The identity operator transforms a tuple set 
in itself, i.e. S 1 = S. 

Proposition 2.4. Domain approximations have the following properties, for any n-tuple 
sets S, Si, S 2 C V n and $ G {1, (5, p}, 

1. idempotency: (S*)* = S*, 

2. monotonicity: Si C S 2 =>• Sf C. Sf, and 

3. closure under intersection: Sf H Sf = (Sf fl 5*)*. Note that in general it is not 
the case that Sf n Sf = (Si n S 2 )* 

We may now define approximation domains, or ^-domains, as follows 

Definition 2.5 (^-domain). A tuple set S is a ^-domain iff 5 = 5* (for $ € {1, <S, 0, /?}). 

Definition 2.6. A domain Si is stronger than a domain S 2 (S 2 is weaker than Si), iff 
<Si C S 2 . Si is strictly stronger than S 2 (S 2 is strictly weaker than Si) iff Si C S 2 . 

The following lemma (proofs for most propositions and lemmas in this paper are given 
in [8]) shows how the previously defined approximations are ordered for a given tuple set 
(or constraint). 

Lemma 2.7. Let S C IT 1 be an arbitrary tuple set. Then, 

S = S 1 C S s C S 13 C S p 

2.3 Propagation 

Definition 2.8 (Propagator). A propagator (or filter) implementing a constraint c G C 
is a function 7r c : gj (P n ) — >■ p (P n ) that is contracting (i.e. tt c (S) C S for any tuple 
set S C D) and sound (it never removes tuples from the associated constraint, i.e. 
con(c)nS C vr c (S)). 

We will assume that propagators are monotonic, i.e. 7r c (Si) C ir c (S 2 ) if Si C S 2 , 
although this property is not mandatory in modern constraint solvers, as shown in [26]. 

Two other properties of propagators are of interest: idempotency and completeness. A 
propagator ir c is idempotent iff n c (ir c (S)) = 7r c (S) for any tuple set S. We denote by 7r* 
the iterated application of propagator ir c until a fixpoint is reached (hence ir c (it* (S)) = 
7T* (S)). Additionally, if propagator tt c is idempotent for any tuple set S we will refer to 
it as 7r*. 

The contracting condition alone sets a very loose upper bound on the output of a 
propagator. Many functions meet these requirements without performing any useful 
filtering (e.g. the identity function). In general, useful propagators aim at being com- 
plete with respect to some domain, thus achieving some consistency on the constraint 
associated with the propagator. 
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Consistency 


<I> VP- co mplet eness 


domain 


<W-complete 


bounds (D) 


5/3-complete 


range 


/35-complete 


bounds (Z) 


/3/3-complete 


bounds (R) 


p/>-complete 



Table 1: Constraint propagator completeness. 

Definition 2.9 (Propagator completeness). A propagator ir c for a constraint c £ C is 
$ ^-complete, denoted as Tr**, iff 

tt* (5) C (con(c)nS*)* 

We should note that when considering real box approximations, con (c) in the above 
definition corresponds to the relaxation of constraint c to the real numbers [26]. Table 
1 shows the correspondence between the constraint consistencies that are traditionally 
considered [26, 22, 20, 5] and the different ^^-completeness of the propagators. 

Example 2.10 (Propagator completeness taxonomy). A hierarchy of the different types 
of $ ^-completenesses described is shown below, where propagators at the start of the ar- 
rows are stronger than those at their end (double arrow denotes strictly stronger propag- 
ators for the shown tuples). The figure considers constraint c = [2x + 3y = z], and the 
arrows are labelled with tuple sets S = S x x S y x S z , where the crossed-out values are 
removed by the stronger but not by the weaker propagator. For example, when applied 
to a domain S = {(0, 1) , (0) , (0, 1,2)}, a domain (<5<5-complete) propagator is able to 
prune tuples (0,0, 1) and (1,0, 1) that a bounds(D) (<5/3-complete) propagator cannot. 

S x 

S. 

s z 



Sy 

s z 



Notice that propagators achieving bounds (D) and range consistency are incomparable, 
as illustrated by the tuple sets that label the two single arrows with opposing directions. 



= {0,1} 
= {0} 
: {0J,2} 



bounds(D) 



my 

{0,1} 
{0,3} 



domain 




bounds (Z) 



{0,1} 
{0,1} 



S z = {t, 2, 3} 

bounds (R) 



S x 


= {oj} 




= {0,1} 




= {0,3} 


range 




/ S x 


= {0} 


Sy 


= {0,1} 


s z -- 


-- {0,2,3} 
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Note also that bounds(IR) completeness is weaker than bounds(Z) completeness, as shown 
in the figure. In particular, whereas a bounds(Z) complete propagator prunes value z = 1 
from the tuples in the figure, this is not the case with bounds(lR) complete propagators 
since (0.5, 0, 1) is a solution of the relaxation of constraint to the real numbers. 
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3 Views for Propagation of Decomposable Constraints 



This section describes propagation of decomposable constraints as a function of views, an 
abstraction representing the pointwise evaluation of a function over a given (tuple) set. 
First we characterize decomposable constraints (3.1). Then we introduce views (3.2), and 
show that they may be used to express sound propagators for decomposable constraints 
(3.3). Section 3.4 briefly discusses propagation strength of view-based propagators, a 
subject that will be revisited later in section 5.3.4 after the implementation details are 
presented. Finally, we introduce box view-based propagators (3.5), a special case of 
view-based propagators that may be implemented efficiently in a straightforward way, as 
described in the rest of the paper. 

3.1 Decomposable constraints 

As previously discussed, constraint solvers do not have a specific propagator for all pos- 
sible constraints. Constraints that cannot be captured by a single specific propagator 
are usually decomposed into a logically equivalent conjunction of simpler constraints for 
which specific propagators exist. Many types of constraints used in practice are decom- 
posable in this sense. Below are some examples. 

Example 3.1 (Arithmetic constraints). These are probably the most common type of 
decomposable constraints. Examples are constraints involving a sum of variables, e.g. 
Ei x i = a nnear combination, e.g. Ei a « x « ^ or a product, e.g. x « = 
While some solvers do have specific propagators for these constraints (e.g. by using the 
notion of linear relation), that approach does not work for more irregular arithmetic 
constraints that may include an arbitrary combination of arithmetic operators, such as 
for example [\x\ — xi\ = 2x3]. 

Example 3.2 (Boolean constraints). Boolean constraints involve Boolean domain vari- 
ables or expressions, for example a disjunction of variables [Vj^iL or more complex ex- 
pressions on Boolean constraints such as disjunctions [\^ (xj > 0)], logical implications 
[x > => y < 0] or equivalences [x > 44> y\. 

Example 3.3 (Counting constraints). Counting constraints restrict the number of oc- 
currences of some values within a collection of variables, for example the EXACTLY(x, v, c) 
constraint (%i = v) = c], or the AMONG(x, V, c) constraint (xj G V) = c]. 

Example 3.4 (Data constraints). Also known as ad-hoc constraints, they represent an 
access to an element of a data structure (a table, a matrix, a relation) [3]. The most 
common constraint in this class is the ELEMENt(x, i, y) constraint enforcing [xi = y] 
where i is a variable. Decomposable constraints involving this constraint are for example 
[xi > y] or [xi - Xj > 0]. 

We propose to express decomposable constraints as a composition of functions. For this 
purpose we will make extensive use of functions that evaluate to tuples, i.e. / : Z n — > Z k 
where k > 1, together with tuple projections, and the usual composition and Cartesian 
product of functions: 
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Definition 3.5 (Functional composition). Functional composition is denoted by operator 
o as usual: (/ o g) (x) = f (g (x)). 

Definition 3.6 (Cartesian product of functions). Cartesian product of functions is de- 
noted by operator x as follows: (/ x g) (x) = (f(x),g(x)). If x is a tuple we may 
write 

(/ x a) {xi, ■ ■ ■ , x n ) = (f (xi, . . . , x n ) , g (xi, . . . , x n )) 

We exemplify our approach to decomposition for some of the constraints given above. 
In the following examples let x, Xi and y represent variables, x represent a tuple of 
variables constant, and pi (x) = Xi the projection operator. 

Example 3.7 (Equality constraint). Let constraint c eq (x) = [xi = X2] be the binary 
constraint stating that variables x\ and X2 must take the same value. A unary equality 
constraint c eqc (x, a) = [x = a] may be obtained by c eqc = [c eq o (p l x f a )], where f a (x) = 
a. 

Example 3.8 (Sum constraint). Let / (x) = x\ + Xi- A sum of three variables is 
represented by / o (/ x ^3). The generalization to a sum of n variables is defined as 

9 = f ° (/ x p 3 ) o (/ x p 3 x p 4 ) o . . . o (/ x p 3 x p 4 x . . . x p n ) 

Therefore we may decompose a constraint for a sum of n variables c sum o (x n ) = Xi = 0] 
&s C sum o = [c eq o g], where c eq o (x) = c eqc (x, 0) defined in the previous example. 

Example 3.9 (Linear constraint). A linear constraint qi n o(a n ,x n ) = EILi a i x i = 0] 
may be decomposed as follows. Let f\, . . . , f n : 7L n — > Z, where /j (x n ) = cijXj. Then, 

QinO = [CsumO 

o (/1 x . . . x /„)], where c sum o is defined in the previous example. 

Example 3.10 (Arbitrary arithmetic constraint). Let / (x) = X\ — x% g{x) = \x\, 
h (x) = 2x. The arithmetic constraint c (x 3 ) = [|xi — X2I = 2x 3 ] may be represented as 

C = [C eq O ((g O / O ( Pl X p 2 )) X (k O p 3 ))] 

Example 3.11 (Exactly constraint). This constraint, represented by (xj = v) = c], 
may be obtained similarly to example 3.9 but where fi (x™) = [xj = v] and the constraint 
c eqc is used instead of c eq o- 

3.2 Views 

In most constraint solvers, domains of subexpressions occurring in constraints are not 
directly available to propagators, which are designed to work exclusively with variable 
domains. In these solvers, an offline modeling phase is responsible for obtaining an 
equivalent CSP where all constraints are flattened, that is where each subexpression 
appearing in a constraint is replaced by an auxiliary variable whose domain is the domain 
of the subexpression. 
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Alternatively, we present a conceptual model that considers explicit subexpression 
domains while abstracting on how they are computed and maintained. This will allow 
us to perform a theoretical analysis of the propagation on the constraint decomposition, 
regardless of the method used for representing the subexpression domains. 

We begin by defining a view as an abstraction which captures the domain of a subex- 
pression in a constraint. 

Definition 3.12 (View). A view over a function / : TU l — > Z k is a pair tp = (^(p^,<pj^ 
of two functions, the image function ip^ : p(Z n ) — > p(Z fc ), and the object function 



A view iff is therefore defined by considering the pointwise application of / over a 
given set. The image function computes a set of images of /, that is the set resulting 
from applying / to all the points in the given set. The object function does the inverse 
transformation, computing the set of objects of / for which its image is in the given set. 

Example 3.13. Consider the view over function / (x) = x + 1 and the unary tuple set 



Notice some similarities of views with indexicals introduced in [17, 6] to create propag- 
ators for arithmetic constraints. An indexical roughly corresponds to the image function 
ip + in the sense that it computes the domain of an expression. However, unlike views, 
indexicals do not define the inverse transformation (p~ and therefore are less powerful - 
representing a decomposable constraint using indexicals requires the additional definition 
of the projection of the object function for each variable in the constraint, even if this 
projection may be performed automatically as shown in [6]. 

As discussed earlier, propagating a constraint may require consulting and updating 
the domain of a subexpression. A view over the subexpression defines these operations: 

Example 3.14. Consider a view ip g over function g(x,y) = x + y, and constraint c = 
[x\ + X2 = X3] on variables x\, X2, X3 with domains D (x±) = D (x 2 ) = D (X3) = {1, 2, 3}. 
Function may be used to compute the subexpression domain D (x\ + x%) from the 
variable domains D (x\) and D (^2), while function (p~ may be used to specify the set of 
values for the variables x±, xi that satisfy constraint c. 



if] : p (Z k ) -»• p(Z n ), defined as 




S = {1,2,3}: 



({1,2,3}) 
^ ({2,3,4}) 



{2,3,4} 
{1,2,3} 



99+ (D (xi) x D (x 2 )) 
¥>J([2...6]) 



[2. ..6] 

{(x,y) £Z 2 :x + y G [2... 6]} 
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Propagation consists of removing inconsistent values from the domain of the variables. 
In this sense, the computation of <pj, i.e. the set of consistent assignments, must be 
intersected with the original domain to guarantee that the propagation is contracting. 
The following definition captures exactly that. 

Definition 3.15 (Contracting object function). Let Si G Z n , S2 £ be two arbitrary 
tuple sets and / : Z n — > T, k an arbitrary function. Then, 

<P f (s 2 ,s 1 ) = <p-f (s 2 )ns 1 

Example 3.16. The result of evaluating and updating the domain D (x\ + x 2 ), as 
defined in the previous example, may be formalized using views as follows: 

( p+(D(x 1 )xD(x 2 )) = [2... 6] 
<p g ([2...6],D(xi)xD(x 2 )) = D (xi) x D (x 2 ) 

3.3 View-based Propagators 

Propagators for decomposable constraints may be obtained by exploring the concept of 
views introduced in the previous section. As illustrated above, an n-ary decomposable 
constraint may be regarded as a special case of functions of the form c o / where / is a 
tuple-function / : IT 1 — > Z fc and c a constraint, mapping k-tuples to the Boolean domain. 

Definition 3.17. Let c be a k-axy constraint for which ir c is a propagator and / be a 
tuple-function / : Z n — > Z k . A view-based propagator for constraint c o /, denoted as 
7c co f, is obtained by 

n cof (S n ) = (p f (vr"* (V+ (£")), S") 

Example 3.18. Consider the view-based propagator for the constraint d = [xi + x 2 = X3], 
and let us analyse the propagation achieved on the tuple set Si = {(1, 2, 3) , (4, 5, 6)}. 

We note that the constraint d can be decomposed into a simpler constraint c = 
[xi = x 2 ] and function g = f x p%, where function g is the Cartesian product of function 
/ (x) = xi + x 2 applied to the 2 initial elements of the tuples {xi,x 2 ,xs) and ps the 
projection to their third element. 

Function 92+ applies the addition and projection operations to the original set, S2 = 
tp+ (Si) = {(3, 3) , (9, 6)}. The resulting set S 2 is filtered by propagator S3 = vr^ 1 * (S 2 ) = 
{(3,3)}, and transformed back into ip g (Ss,Si) = {(1,2,3)}. 

3.4 Approximate view-based propagators 

In this section we present approximate view-based propagators and relate them to the 
completeness classes introduced in table 1 on page 7. 

Definition 3.19 (^^ — complete view-based propagator). A view-based propagator 
for a constraint c o / is defined as 

*%*(S) = ?/(7r c 11 *o ¥ ,+ (5*),5*)*nS ) where* ) *€{l,<J^} 
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Intuitively, ^^-completeness of a view-based propagator for a decomposable constraint 
of the form c o fi ■ ■ ■ o f m is obtained by approximating the input of the image function 
(p^ and the output of the object function (pf, and not approximating the remaining 
view functions or propagators involved. For these view-based propagators the following 
property can be proved [8]. 

Proposition 3.20. A view-based propagator for a constraint co / is a -complete 
and idempotent propagator for co f. 

The use of the above proposition is rather limited since it applies only to a propagator 
7r c that is 11-complete and idempotent. Achieving such completeness is usually intract- 
able in time and/or space in general, inequality constraints being a notable exception. 
Moreover other approximations are performed in practical view-based propagators, which 
are now presented. 

3.5 Box view-based propagators 

A box view-based propagator (or simply box view propagator) is a relaxation of a f3(3- 
complete view-based propagator. In addition to the /^-approximations already presented, 
it 

1. /3-approximates the output of the image function p + , 

2. /3-approximates the input of the contracting object function <p, 

3. uses a /3/3-complete and idempotent propagator for c 

To simplify its formalization, we use the following notation for special applications of 
5>- approximations to views: 

* f (S u S2) = (p f (Sf,Sf)f 
We may now formalize box view-based propagators. 

Definition 3.21 (Box view-based propagator). A box view-based propagator for a con- 
straint c o / is defined as 

*£/ (S) = f (vrf * (/3+ (S)) ,s)nS 

Box view-based propagators allow very efficient implementations since /3-domains may 
be stored in constant space (the domain is fully characterized by its lower and upper 
bound), and computing views on /3-domains does not depend on the size of the domain 
for most functions. 
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Example 3.22. Let / (x) = \x\ and Si, S 2 Q two arbitrary sets of unary tuples, and 
assume [S 2 \ > 0. By definition, 



This definition may suggest that evaluating these functions would take linear time, but 
in fact they may be computed in constant time assuming that finding the minimum and 
maximum of Si, S2 takes constant time: 



A thorough analysis of the propagation achieved with box view propagators is complex 
and dependent on the constraints involved (see [8]). Here we only present a sufficient 
condition for a box view based propagator to be bounds (R) complete. 

Proposition 3.23. A box view-based propagator for co f is always at least bounds(R) 
complete if f is continuous. 




Pi (ft) 




Pf(S2,Sl) 



' [max ( L5 2 J , [Si\ ) . . . min ( \S 2 ] , \Si] )] <= [Si\ > 

< [max (- \S 2 ] , L^iJ ) . . . min (- L^J , )] <= \S{\ < 
k [max (- \S 2 ] , [Si\ ) ... min ( [S 2 1 , [Sil )] otherwise 



Proof. 




(def. 3.21) 



(def.2.9) 



Given that (p+ (5)) = /?+ (S) and (3j (S^) = f3j (S), 

*cof (S) =P f (con (c) n /?; (S) ,s)ns 



Since con (c) C conu (c), S 13 C S p for any S C Z n , and all operators are monotonic, 




Note that when / is continuous the following is true, 



P + is) = (tf {s'j) p = (sn 

p f (Si, s 2 ) = (ip f (s p 1} s 2 )) p = [tp f (Si, s 2 )y 
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Rewriting the above expression using these equivalences gives, 



cof 



(S) C (con R (c)n^+(SP),s)Y 



ns 



(def.2.9) 



□ 



So far we have been discussing view based propagators obtained from composition 
of views with propagators that are idempotent. Some practical propagators are non- 
idempotent (or have non-idempotent implementations) for efficiency reasons. Unfortu- 
nately, the strength of a view based propagator for co / is influenced by the idempotency 
of the underlying propagator 7r c . 

Proposition 3.24. A box view-based propagator for a constraint cof is stronger than a 
corresponding view-based propagator using a non-idempotent propagator ir c for c. Moreover, 
it may be strictly stronger. 

The fact that a view-based propagator for a constraint cof with an idempotent 
propagator for c achieves at least the same pruning as with a non-idempotent propagator 
for c is not surprising since it* is always stronger than tt c and all other involved functions 
and operators are monotonic. The following example shows it can indeed achieve more 
pruning. 

Example 3.25. Let c o / = [2 ■ X\ ■ xi = x 3 ] be a decomposable constraint, where c = 
[2 ■ X\ = X2] and / (x±, X2, X3) = {x\ • X2, £3). A box view-based propagator tt^ ^ applied 
to D = [2 ... 3] x [2 ... 3] x [9 ... 15] leaves the domains of x\ and X2 unchanged, but 
prunes the domain of X3 since 



Now consider the following non-idempotent propagator ttc for the same constraint c: 



Unlike in the previous case, the box view propagator obtained from composition with 
the non-idempotent propagator ir c would not achieve any pruning, since 



7rf*([4...9]x[9...15]) 
/3/Q5...7] x [10...14],D)nD 



[4 

[5 
[2 



9] x [9 . . . 15] 

7] x [10 . . . 14] 

3] x [2 ... 3] x [10 .. . 14] 




<r- D (x 3 ) n [[D (x 1 x x 2 )\ x 2 ...\D (xi x x 2 )~\ x 2] 
<- D (xi x x 2 ) n [[D (x 3 )\ /2...\D (x 3 )l /2] 



P+(D) [4... 9] x [9... 15] 

tt^([4...9] x [9... 15]) = [5... 7] x [9... 15] 
/3/Q5...7] x [9...15],D)nD = [2 . . . 3] x [2 . . . 3] x [9 . . . 15] 
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The reason for this may be explained as follows: not being idempotent, the change in 
the domain of D (x\ x X2) is not immediately propagated back to D (#3) but instead is 
approximated back to the initial value by the encapsulating view functions, fij and f3f. 
Therefore, the subsequent application of the box view propagator to have no effect. 

The above proposition explains the differences in propagation strength between de- 
compositions using auxiliary variables and view objects. With variable decomposition, 
non-idempotent propagators for sub-expressions will always act as idempotent propagat- 
ors: sub-expressions are propagated independently and will be added to the propagation 
queue until a fix point is reached. In theory this means that decompositions using auxil- 
iary variables may attain stronger propagation. In practice these differences do not seem 
to be very significant, and are compensated by other factors as the experimental results 
presented later suggest. 
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4 Implementation 



Implementation of views for an arbitrary expression may be complex, depending on 
the type of approximations the view is considering. For the specific case of box view 
propagators, the code that implements a view over an expression e should be no more 
complex than the code for a propagator of e = z, where e is an expression involving 
variables (i.e. not other expressions) and z is a variable. For example, implementing 
a box view for the expressions e\ + e2, or e\ x e2, where e, are expressions is very 
similar to implementing the propagator for x\ + xi = £3, or x\ x X2 = X3, where X{ are 
variables. The simplicity of these implementations is in fact a key advantage of box view 
propagators. The following sections provide some examples of such implementations. 

4.1 Box view propagators in strongly typed programming languages 

Implementing our conceptual box view propagator in a strongly typed programming lan- 
guage is possible if some sort of type polymorphism support is available in the language. 
Most if not all popular strongly typed programming languages have built in support for 
subtype polymorphism, either by overloading or through the use of inheritance in the 
case of object oriented programming languages. In addition, parametric polymorphism 
has been introduced in some object oriented programming languages such as C+ + , Java 
and C#. Parametric polymorphism allows aggressive compiler optimizations, namely 
function code inlining (i.e. replacing function calls by the actual code), which has a 
significant impact on performance as we will see later. 

We have implemented box view propagators in C++. Since C++ supports both sub- 
type and parametric polymorphism, we were able to integrate the two variants of our 
model within the constraint solver engine, therefore obtaining a fair experimental plat- 
form. 

4.1.1 Subtype polymorphism 

Subtype polymorphism is available in C++ through the use of inheritance. In this setting 
we need to define an abstract interface for box view objects: 

class Box { 

virtual int getMin() = 0; 

virtual int getMax() = 0; 

virtual bool updMin(int i)=0; 

virtual bool updMax(int i) = 0; 

h 

A box view object for a specific function implements the box view object interface 
(for convenience the update methods return whether the operation does not result in an 
empty box). 

Example 4.1. The following class defines the subtype polymorphic box view object for 
the addition of two box view objects. 
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class Add2 : Box { 

Add2(Box ax, Box ay) : x(ax) ,y(ay) {} 

virtual int getMinQ { return x . getMin () + y . getMin ( ) ; } 
virtual int getMaxQ { return x . getMax() + y . getMax ( ) ; } 
virtual bool updMin(int i) 

{ return x . updMin ( i—y . getMax () ) and y . updMin ( i — x . getMax ()); } 
virtual bool updMax(int i) 

{ return x . updMax( i — y . getMin () ) and y . updMax( i — x . getMin ()); } 
Box x ; 
Box y; 

h 

We should note that for the sake of simplicity we omit details on the efficient copy 
and garbage collection of box view objects. Compiling a given constraint into subtype 
polymorphic box view objects is straightforward since in C++ expressions are evaluated 
bottom-up. Below are a set of convenience functions which may be used to create subtype 
polymorphic view box objects for a binary addition. 



Add2 add (Box x,Box y) 
{ return Add2(x ,y ) ; } 

Add2 operator +(Box x , Box y) 
{ return Add2(x,y); } 

The user may then create box view objects for arbitrary expressions in C++ using a 
clean syntax: 

DomVar a , b , c ; 
a+b*c ; 

add (a , mul(b , c ) ) ; 

From what we could infer from the available documentation, constrained expressions 
introduced in ILOG Solver [18] correspond to box view objects implemented using sub- 
type polymorphism as shown above. 

4.1.2 Parametric polymorphism 

The fact that the C++ compiler evaluates expressions bottom-up makes the implemen- 
tation of parametric polymorphic view objects slightly more complex, since they need 
to be compiled top-down. The solution we propose breaks the compilation algorithm in 
two phases. The first phase creates a syntactic representation of the expression, called a 
type parametric relation object, using the natural bottom-up evaluation order intrinsic 
in the language. Type parametric relations capture the data and the type of the objects 
and operations involved in the constraint. After the full constraint is compiled, we use 
the obtained relation object for instantiating the required view objects. 

We will use templates for defining type parametric relations, since this is the language 
mechanism available in C++ to support type parametric polymorphism. The following 
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template defines generic binary relations, where "Op" is a type describing the operator, 
and "X" and "Y" are types of the operands. 

template<class Op, class X, class Y> 
class Rel2 { 

Rel2(X x, Y y) : x(x) ,y(y) {} 

X x ; 

Y y; 

h 

Since any expression may be transformed to a relation object with a unique type, we 
can create view objects over arbitrary expressions by defining templates over relation 
objects. 

Example 4.2. The following template defines the parametric polymorphic box view 
object for the addition of two arbitrary objects: 

template<class X, class Y> 
class Box<Rel2<Add,X,Y> > { 

Box(Rel2<Add,X,Y> r) : x ( r . x ) , y ( r . y ) {} 

int getMinQ { return x . getMin () + y . getMin ( ) ; } 

int getMaxQ { return x . getMax() + y . getMax ( ) ; } 

bool updMin(int i) 

{ return x . updMin ( i — y . getMax () ) and y . updMin ( i — x . getMax ()); } 
bool updMax(int i) 

{ return x . updMax( i—y . getMin () ) and y . updMax( i—x . getMin ()); } 
Box<X> x ; 
Box<Y> y ; 

}; 



Parametric relation objects are created by a set of convenience functions, such as: 

template<class X, class Y> 

Rel2<Add,X,Y> add(X x,Y y) 

{ return Rel2<Add ,X, Y>(x , y ) ; } 

template<class X, class Y> 

Rel2<Add,X,Y> operator + (X x,Y y) 
{ return Rel2<Add ,X, Y>(x , y ) ; } 

Note that the above functions only create the relation object for the expression, and 
not the corresponding view object. Creating the view object is accomplished by providing 
the relation object to the following function (which is basically a convenience function 
to avoid specifying the parameter T): 

template<class TY 

BoxYlY box(T t) 

{ return BoxYT>(t ) ; } 

The following code instantiates two parametric box view objects for an expression 
using the above constructs. 
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DomVar a , b , c ; 

box (a+b*c ) ; 

box ( add ( a , mul ( b , c ) ) ) ; 



4.2 Incrementality 

It is important to note that incremental propagators (i.e. propagators which maintain a 
state) may be used transparently with views. This may be very useful in practice, for 
example to model the bounds complete distinct propagator over expressions, such as the 
main constraint of the Golomb ruler problem (given in the next section), 

DISTINCT ({xi - Xj : 1 < j < i < m}) 

There is also nothing preventing us from creating views that maintain an internal state. 
Although we have implemented this for some expressions, namely the ELEMENT expres- 
sion, it does not seem to be useful for most f3(3 views that are cheap to evaluate. However, 
it could certainly make a difference if using 55 views for domain propagation. In sum- 
mary, using views does not constrain the propagator implementation model to be either 
incremental or non-incremental. 

4.3 Triggering 

Triggering is a well known method for decreasing the number of redundant propagations 
during a fixpoint computation [23]. A trigger may be seen as a condition for propagation 
- propagators are known to be idempotent for the current domain until the condition is 
true, i.e. when they may perform propagation. The way triggering is used with views is 
not much different from its use in the variable decomposition approach. In addition to the 
methods presented above, each view object must provide methods for creating/deleting 
triggers on the relevant events. This must be adapted to the events available in the 
solver: for example, a trigger on both bounds of an expression x + y should map to the 
four bounds of x and y, whereas a trigger on the minimum of —x maps to the maximum 
of x. 

Given that each view object provide methods for creating and removing triggers, mov- 
ing triggers is also possible using views. Consider for example a box view over the 
expression IfThenElse(C, T, F) which represents the box T if C is true, and F if it is 
false. Initially the box view object for this expression creates triggers on C, T, and F 
(note that inference can be made even if C is not ground). When C is instantiated it 
removes the trigger on either T or F. We should make two important remarks about 
creating/deleting triggers. Firstly, at least in our current implementation, moving trig- 
gers is not as efficient as in e.g. [14]. This is due to the fact that it is recursive on 
the structure of the expression (consider for example creating a trigger on an expression 
containing deeply nested expressions). This is tantamount with other aspects of views - 
a specialized propagator for the constraint will always have better runtime performance. 
Secondly, view objects must always check beforehand if it is safe to move a trigger. In 
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our example, the box view object must check if C is ground (i.e. if getMin()=getMax()) 
before deleting the relevant triggers, even if it has updated the domain of C itself. This 
has to do with (non) persistence of update operations explained in the following section. 

4.4 Persistent operations and idempotency checking 

An important feature of box view objects is that operations are not guaranteed to be per- 
sistent. Consider for example the constraint c = [X 7^ k], where X is an expression and 
k is a constant. The pseudocode for a bounds consistent propagator for this constraint 
is as follows: 

1 bool propagate (Box<int> X, int k) { 

2 if (X.min()==k) 

3 return X. updateMin (k + 1) ; 

4 if (X.max()==k) 

5 return X. updateMax (k — 1 ) ; 

6 return true ; 

7 } 

This propagator may be used for propagating several constraints by specifying differ- 
ent expressions for X, for instance the constraints c\ = [x\ / k] and C2 = [yi + 2/2 7^ k] 
where X is respectively x\ and y\ +2/2- While lines 3 and 5 guarantee that the domain 
of expression X will be different from k when propagating constraint c±, this is not guar- 
anteed when propagating constraint C2 (consider for example D (y\) = D (1/2) = {1,2} 
and k = 4). In this simple propagator the fact that some update operations are non- 
persistent is not important: the propagator will be scheduled again when either the 
minimum or maximum of X changes, eventually leading to a persistent update. In gen- 
eral, view based propagators must be designed to take non-persistent update operations 
into consideration. The class of propagators that check for idempotency deserves special 
attention. 

Idempotency checking is a technique for decreasing the number of redundant propa- 
gations during solving. The main idea is to avoid scheduling propagators that report 
idempotency for a given domain since no further pruning would be achieved. A naive 
(but incorrect) implementation of this optimization on the propagator above would be 
as follows: 

status propagate (Box<int> X, int k) { 
if (X.min()==k) 

return (X. updateMin (k + 1 ))? idempotent : failed ; 
if (X.max()==k) 

return (X. updateMax (k — l))?idempotent : failed ; 
return suspend ; 

} 

In the above pseudocode a propagator can be in one of three states: failed (i.e. in- 
consistent for the current domain), idempotent, or suspended (i.e. neither failed nor 
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Figure 1: An unbalanced expression syntax tree. The internal nodes n\. . . n n -\ represent 
operators and leafs l\ . . .l n represent variables. 

idempotent). Due to non-persistent operations for some instantiations of X this propa- 
gator may report "idempotent" when in fact it is not. Instead, a correct implementation 
of this optimization must not rely on persistent update operations: 

status propagate (Box<int> X, int k) { 
if (X.min()==k) 

{ 

if (X. updateMin(k + l)) 

return (X. min() >k) ? idempotent: suspend; 

else 

return failed ; 

} 

if (X.max()==k) 

( similar ) 
return suspend ; 

} 

In summary, checking for idempotent view-based propagators is possible but must be 
carefully designed in order not to rely on persistent update operations as shown above. 

4.5 Complexity analysis 

The adoption of views avoids introducing auxiliary variables and propagators for every 
subexpression. Conceptually, a view object over an expression serves the same purpose as 
the auxiliary variable introduced for that expression: to expose its domain. However these 
models have distinct operational tradeoffs. To illustrate this let us focus on an arithmetic 
constraint involving n variables with uniform domain size d, with an unbalanced syntax 
tree, i.e. where each operator in the expression involves at least one variable. Figure 1 
shows a fragment of the expression syntax tree. We will refer to the decomposition model 
using auxiliary variables as VARS, subtype polymorphic view as SVlEWS, and parametric 
polymorphic views as PVlEWS. 



22 



4.5.1 Memory 

A box view object can be designed to expose just the subset of the expression's domain 
required for the view's client (e.g. the bounds of the expression). In contrast, a variable 
maintains the domain of the expression, possibly containing regions that will always be 
ignored for propagation. For an expression containing n—1 operators (fig. 1), the memory 
overhead of the VARS model is in O (nD), where D is the size of the largest domain of 
an auxiliary variable. In practice, although D may be as large as cP -1 , many solvers 
[12, 13, 18] use intervals to store the domains of the auxiliary variable (i.e. D = 2), thus 
eliminating this problem. 

4.5.2 Runtime 

The analysis of runtime complexity focuses on the number of propagator executions, 
function calls, arithmetic operations performed and updates of variable bounds, for a 
single propagation of the expression. We consider two worst-case situations: a) when 
propagation (up to the root) is due to a change in the domain of a leaf variable, and 
b) when propagation to leaf variables is caused by a change in the domain of the root. 
These situations correspond, respectively, to accessing and updating the bounds of the 
expression. 

a) In the VARS model O (n) propagators may execute, forcing changes in the bounds of 

O (n) (auxiliary) variables with O (n) operations. In both view models, an update 
of a leaf variable domain causes one single propagator to execute and evaluate the 
full expression. Such evaluation requires O (n) function calls and O (n) operations 1 . 

b) In the VARS model O (n) propagators may execute, forcing changes in the bounds 

of up to O (2n) variables (n leaf variables and n — 2 auxiliary variables), requiring 
up to O (n) operations. Both view models force O (n) updates of bounds of the 
(leaf) variables, through O (n) function calls and O (n) operations, but no extra 
propagators will execute. 

Although all the models present the same worst-case propagation complexity of O (n 2 d), 
breaking down the costs shows that the view models perform fewer calls to propagators 
and fewer variable updates (there are no auxiliary variable) than the VARS model. The 
fundamental operational difference between the VARS model and both view models is that 
a view object computes its domain on demand, that is, it will never update its domain 
before needed by the view's client, in contrast with the VARS model, where additional 
propagators will be posted to prune the domains of the auxiliary variables. Among 
all contributions, managing the extra propagators should involve the most significant 

*A single update of the expression requires the evaluation of the full tree, possibly involving n 2 total 
operations (as well as n 2 function calls in case of the S Views model), if subexpressions are evalu- 
ated multiple times recursively. It is possible to decrease this number to n if the evaluation of the 
subexpressions is cached during the execution of the propagator. This may be done efficiently with 
box views since the cached data is simply the two bounds of the subexpression that do not have to 
be backtrackable. 
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costs. On the other hand, the view models require extra operations and function calls. 
Overall, and despite the same worst-case complexity we expect that the VARS models, 
that may suffer from the execution of more propagators, are out-performed by the VIEWS 
models, specially by the PVlEWS where the compiler is often able to avoid the overhead 
of function calls using inlining. But these expectations can only be adequately assessed 
by experimentation, so in the next section we present results obtained in a comprehensive 
set of experiments. 
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5 Experimental Results 



In this section we evaluate the performance of the decomposition methods described in 
the previous sections on a set of benchmarks. 

5.1 Experiments 

Specifically we are interested in comparing the following models. 

5.1.1 Models 

VARS. This is the classical method for decomposing constraints into primitive propag- 
ators introducing one auxiliary variable for each subexpression. 

VARS+ Global. This model is similar to the previous but uses global constraints for 
lowering the number of auxiliary variables. Only a subset of problems support this 
decomposition in which case we will specifically mention which global constraints 
are used. 

PVlEWS. The model that implements the decomposition based on parametric poly- 
morphic view objects. 

SVlEWS. The decomposition based on subtype polymorphic view objects. 

VIEWS+ GLOBAL. Like the VARS+GLOBAL model, this model uses a combination of 
some type of views and a global constraint propagator. 

All the above decomposition models were implemented in CaSPER [9, 10]. Additionally, 
we also implemented the first two in Gecode [12] denoted Gecode-Vars and Gecode- 
VARS+GLOBAL respectively. Comparing to the Gecode solver assesses the competit- 
iveness of CaSPER as a whole, in order to clarify that the performance of using our 
method for propagation compared to using auxiliary variables is not due to an inefficient 
implementation of the latter. 

5.1.2 Problems 

The set of benchmarks covers a total of 22 instances from 6 different problems. Before 
we present them in detail, we should make a few general considerations. 

For each given instance we used the same labeling heuristics (or no heuristics at all) 
for testing the above models. This means that, for each instance, the solvers resulting 
from the implementation of the above models explore exactly the same search space, 
unless the decompositions have different propagation strength, which may occur as we 
have already seen. 

In the following, we will mostly focus on the decomposable constraints for which our 
models apply. When describing the model, we may choose to ignore other necessary, 
redundant, or symmetry breaking constraints that we used in our implementations. These 
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were kept constant across all implementations of the above models for each benchmark 
and therefore do not influence our conclusions. For additional information, we provide 
references to detailed descriptions of the problems in the online constraint programming 
benchmark database CSPLib [16]. The source code for all the implementations can be 
obtained from the first author upon request. 

Systems of linear equations. This experiment consists in solving a system of linear 
equations. Linear equations are usually integrated in Constraint Programming using a 
specific global constraint propagator. The goal of the experiment is therefore to assess 
the overhead of decomposing expressions using the presented models compared to a 
decomposition which uses a special purpose algorithm, i.e. a global constraint. 

Each system of linear equations is described by a tuple (n, d, c, a, s\u) where n is the 
number of variables in the problem, d is the uniform domain size, c is the number of 
linear equations, a is the number of terms in each equation, and the last term denotes if 
the problem is (s)atisfiable or (u)nsatisfiable. Each problem is defined by 



where p (i) is a function returning a combination of a variables for the equation i, selected 
randomly from the full set of C™ possible combinations. The independent term t in each 
equation was selected randomly with a uniform probability from the interval [a ... a X d]. 
Different random seeds were experimented in order to generate difficult instances. 

The a-ary sum constraints were decomposed using binary sums implementing a sub- 
set of the previously described models, namely VARS, SVlEWS, and PVlEWS. Model 
VARS+GLOBAL used global constraint propagators for the a-ary sums (in this case no 
auxiliary variables are required). 

Systems of nonlinear equations. The second experiment considers systems of nonlin- 
ear equations. These problems arise often in practice, and since the decomposition to 
special purpose propagators is not so direct as in the previous case, it provides a realistic 
opportunity to apply the previously discussed models. 

A system of nonlinear equations is described by a tuple (n, d, c, a±, 0,2, s\u) where a± is 
the number of terms in each equation, each term is composed of a product of ai factors, 
and all remaining variables have the same meaning as before. Each system of nonlinear 
equations is formally defined as: 



where p(i,j) is a function returning a combination of 02 variables for the term j of 
equation i, selected randomly from the full set of C™ 2 possible combinations. 

The tested models consist of the decomposition into binary sums and products using 
auxiliary variables exclusively (Vars) and using view models (S VIEWS, PVlEWS). We 



c 




i=l v£p(i) 




i=l j=l vEp(i,j) 



26 



also tested two models where each product is decomposed using either auxiliary variables 
or views, projected to a variable Xj, and a sum propagator is used to enforce YliLi x % f° r 
each equation (VARS+GLOBAL and PVlEWS+GLOBAL respectively). 



Social golfers (problO in CSPLib). The Social golfers problem consists in scheduling a 
golf tournament. The golf tournament lasts for a specified number of weeks w, organizing 
g games each week, each game involving s players. There is therefore a total of g x s 
players participating in the tournament. The goal is to come up with a schedule where 
each pair of golfers plays in the same group at most once. 

This problem may be solved efficiently in Constraint Programming using a 3-dimensional 
matrix x of w x g x s integer domain variables, where each variable identifies a golf player 
in the tournament. For two groups of players G±, G 2 , the MeetOnce constraint ensures 
that any pair of players in one group does not meet in the other group, 



meetOnce (Gi, G2) 



xeGi,yeGi 



This constraint is then used to impose that each pair of players meets at most once 
during the entire tournament, 



y\ meetOnce 

l<Wi<Wj<W 



{x Wi , gi , Si ■ 1 < 9i < 9 A < Si < s} , 
{x Wj , gj , Sj ■ 1 < 9j < 5,1 < Sj < s} 



We tested a subset of our models for propagating the MeetOnce constraint, namely 
PViews+Global, SViews+Global, and Vars+Global. View based models im- 
plement the meetOnce constraint using the above expression directly using a global 
propagator for the sum constraint: 

meetOnce (Gi, G 2 ) = [sum (all (x g Gi,y e G 2 ,x = y)) < 1] 

The ALL predicate is used for aggregating a set of expressions from the instantiation of 
a template expression (e.g. x = y) over a set of possible values (e.g. x G G±,y G G2). 

The VARS+GLOBAL model implements the traditional decomposition using a set b of 
s 2 auxiliary boolean domain variables, 



meetOnce (Gi,G 2 ) = f\ [k = (x = y)] 

xeGi,yeG 2 



A 



E^ 1 



i=l 



(1) 
(2) 



In this case we used the (reified) equality propagator for each equation in the conjunction 
of eq. 1, and a sum global propagator for eq. 2. 
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Golomb ruler (prob6 in CSPLib). A Golomb ruler of m marks and length set 
of m integers, 

= X\ < X2 < ■ ■ . < x m 
such that the m(m — l)/2 differences X 2 j ? 

1 < j < i < m are distinct. The Golomb 
ruler problem is an optimization problem, where the goal is to find the smallest possible 
Golomb ruler with a given number of marks. 

This problem makes use of a constraint of the form 

DISTINCT ({xi — Xj : 1 < j < i < m}) 

enforcing that the pairwise differences all distinct. The classical decomposition 

for this constraint (VARS+GLOBAL) introduces one auxiliary variable for each pairwise 
difference, and makes use of the distinct global propagator for the DISTINCT constraint, 



A 



l<i<j<m 

A 



[0-i,j — Xi Xj] 
[DISTINCT (a)] 



Using views avoids introducing the set of auxiliary variables a. Instead, the constraint 
is used directly as follows, 

DISTINCT (ALL (1 < % < m, 1 < j < m, j < i, Xi - Xj)) 

and enforced with the bounds complete propagator introduced by [19]. In our benchmarks 
we solved the decision version of this problem, i.e. we provided the size of the ruler x m 
as a parameter of the problem, and asked for a ruler satisfying the constraints. 



Low autocorrelation binary sequences (prob5 in CSPLib). The goal is to construct 
a binary sequence S = x\, . . . , x n of length n, where D (xj) = { — 1, 1}, 1 < i < n, that 
minimizes the autocorrelations between bits, i.e. that minimizes the following expression, 

2 



rn 



n—l I n—i—1 

^1 x j X x j+i+l 

i — ' V j l 



(3) 



The VARS+GLOBAL model decomposes the above expression using three sets of auxiliary 
variables a, b, and c, and sum constraints as follows, 



n— 1 a n—i—1 r 
i=l /\j=l i 
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m = ^2ci 
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The P VIEWS, and S VIEWS models implements expression 3 directly, without introdu- 
cing any auxiliary variable. 
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Fixed-length error correcting codes (prob36 in CSPLib). This problem involves gen- 
erating a set of strings from a given alphabet which satisfy a pairwise minimum distance. 
Each instance is defined by a tuple (a, n, I, d) where a is the alphabet size, n is the num- 
ber of strings, I is the string length, and d is the minimum distance allowed between any 
two strings. For measuring the distance between two strings we have used the Hamming 
distance on two instances and the Lee distance on the other two. For two arbitrary 
strings x, y of length I, these measures are defined as follows, 

I 

Hamming (x, y) = ^ (a* / Vi ) 
i=i 
i 

Lee (x, y) = ^min(|xj - yi\ ,a - \x t - yi\) (4) 

i=l 

This problem was modeled by a matrix x of n x I integer domain variables, where each 
variable Xjj can take a value in 1 ... a corresponding to the symbol of string i in position 
j. Then, distance constraints are imposed between each pair of strings, 

f\ DISTANCE ({x ild :l<j<l}, {x i2tj :l<j<l})>d 

l<ii<i2<n 

The VARS+GLOBAL model decomposes distance constraints using auxiliary variables 
and sum constraints. Note that in the case of the Lee distance, a total of 41 auxiliary 
variables are introduced for each distance constraint. The SVlEWS, and PVlEWS models 
implement both distance functions without any extra variables. 

5.2 Setup 

The experiments were compiled with the gcc-4.5.3 C++ compiler and executed on an Intel 
Core i7 @ 3.39GHz running Mac OS X 10.7.4. The versions of the CaSPER and Gecode 
solvers were the most recently available at the time of these experiments, respectively 
version 1.0.0rc2 and version 3.7.3. Each benchmark was repeated ten times and then 
kept repeating until the standard deviation of the runtime was below 2% of the average 
time. The minimum runtime was then used. The source code for all experiments can be 
made available upon request (please email the first author). 

5.3 Discussion 

The results of all benchmarks are summarized in tables 2 to 6 (more detailed in [8]) from 
which we may draw the following conclusions. 

5.3.1 Type parametric views versus Subtype polymorphic views 

Recall from section 4.1 on page 17 that solvers using type parametric view objects are 
able to avoid a number of function calls due to code inlining optimizations. Table 2 
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mean 


stddev 


min 


max 


Systems of linear equations 


0.44 


1.87 


0.24 


0.97 


Systems of nonlinear equations 


0.74 


1.02 


0.72 


0.75 


Social golfers 


0.70 


1.03 


0.68 


0.72 


Golomb ruler 


0.98 


1.02 


0.95 


1.00 


Low autocorrelation binary sequences 


0.92 


1.01 


0.91 


0.92 


Fixed-length error correcting codes 


0.56 


1.44 


0.39 


0.77 


All 


0.67 


1.48 


0.24 


1.00 



Table 2: Geometric mean, standard deviation, minimum and maximum of the ratios 
between the runtimes of the solver implementing the PVlEWS model and the 
solver implementing the SVlEWS model, on all benchmarks. 

shows how this optimization improves performance in practice. Overall the speed-up of 
PViews wrt. SViews is 50% (i.e. 1/0.67 — 1). In particular for problems involving a 
large number of subexpressions the speed-up can reach up to 300%. Given that type 
parametric views are consistently better, we choose to use this model exclusively on the 
remaining experiments. 

5.3.2 Auxiliary variables versus Type parametric views 

Table 3 compares the runtime of the best model using auxiliary variables, i.e. either 
VARS or VARS+GLOBAL, with the runtime of the best model that uses type parametric 
views, i.e. either PVlEWS or PVlEWS+GLOBAL. View objects do not intend to be a 
replacement for global constraint propagators, and therefore this table shows how much 
the runtime of a constraint program may be improved when using the best available 
tools. 

Before we take a global view on the results in this table, let us focus on the special case 
of the benchmark involving systems of linear equations. We recall that this benchmark 
should not be considered as part of a realistic application of views or auxiliary variables 
since it may be modeled using a global constraint propagator exclusively. However, 
modeling the global sum constraint using type parametric views over binary sums was 
only 10% worse on average, which is nevertheless remarkable. 

For all other benchmarks, using type parametric views instead of auxiliary variables was 
consistently better, approximately twice as fast on (geometric) average, and always more 
than 33% faster. An interesting particular case are the two instances of the "Fixed length 
error correcting codes" problem using the Lee distance. These instances are in fact the 
only ones for which decomposing using auxiliary variables could be recommended. This 
is because there is a subexpression which occurs twice in the expression, and therefore 
can be represented by the same auxiliary variable (see equation 4), possibly leading to 
a smaller search tree. Even without this optimization, the solver using type parametric 
views was almost twice as fast on average on these instances. 

Regarding propagation, even if using auxiliary variables may sometimes lead to smaller 
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mean 


stddev 


min 


max 


Systems of linear equations 


1.10 


1.14 


0.96 


1.24 


Systems of nonlinear equations 


0.38 


1.08 


0.34 


0.41 


Social golfers 


0.28 


1.29 


0.22 


0.36 


Golomb ruler 


0.75 


1.07 


0.70 


0.80 


Low autocorrelation binary sequences 


0.24 


1.01 


0.24 


0.24 


Fixed-length error correcting codes 


0.60 


1.30 


0.42 


0.79 


All 


0.51 


1.73 


0.22 


1.24 


All except linear 


0.43 


1.55 


0.22 


0.80 



Table 3: Geometric mean, standard deviation, minimum and maximum of the ratios 
between the runtimes of best performing model using views and the best per- 
forming model using auxiliary variables, on all benchmarks. 





mean 


stddev 


min 


max 


Systems of nonlinear equations 


1.06 


1.08 


1.01 


1.16 


Golomb ruler 


1.00 


1.00 


1.00 


1.01 


Fixed-length error correcting codes 


1.20 


1.00 


1.20 


1.20 


All 


1.06 


1.08 


1.00 


1.20 



Table 4: Geometric mean, standard deviation, minimum and maximum of the ratios 
between the number of fails of the best performing solver using views and the 
best performing solver using auxiliary variables, on all instances of each problem 
where the number of fails differ. 

search trees (due to proposition 3.24), the difference was not significant in our experi- 
ments. In fact, for those instances where using auxiliary variables increases propagation 
strength compared to views, the discrepancy in the number of fails was only of 6% on 
average, and never more than 20% (table 4). 

5.3.3 Competitiveness 

Modeling decomposable constraints using type parametric views makes CaSPER com- 
petitive with the state-of-the-art Gecode solver. This may be seen by comparing the 
results presented in table 5 and table 6. In the first table we compare the runtimes 
obtained by running the same model on both solvers, i.e. VARS+GLOBAL and GECODE- 
Vars+Global. The second table compares the PVlEWS model against GECODE- 
VARS+GLOBAL, which are the best models that can be implemented in both platforms 
using the available modeling primitives. While CaSPER is worse in all but one prob- 
lem when using auxiliary variables and global propagators, it becomes faster when using 
type parametric views. We believe that the discrepancy observed in the "Fixed length 
error correcting codes" benchmark is related to aspects of the architecture of both solvers 
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mean 


stddev 


min 


max 


Systems of linear equations 


1.23 


1.41 


0.73 


1.50 


Systems of nonlinear equations 


2.06 


1.06 


1.90 


2.16 


Social golfers 


2.00 


1.28 


1.51 


2.38 


Golomb ruler 


1.68 


1.29 


1.25 


2.01 


Low autocorrelation binary sequences 


1.84 


1.01 


1.83 


1.85 


Fixed-length error correcting codes 


0.11 


2.23 


0.04 


0.21 


All 


1.01 


3.30 


0.04 


2.38 


All except fixed-length error correcting codes 


1.72 


1.33 


0.73 


2.38 



Table 5: Geometric mean, standard deviation, minimum and maximum of the ratios 
between the runtimes of the CaSPER solver implementing the VARS+GLOBAL 
model and the Gecode solver implementing the VARS+GLOBAL model, on all 
benchmarks. 





mean 


stddev 


min 


max 


Systems of linear equations 


1.35 


1.56 


0.71 


1.86 


Systems of nonlinear equations 


0.78 


1.08 


0.72 


0.86 


Social golfers 


0.57 


1.42 


0.45 


0.85 


Golomb ruler 


1.26 


1.24 


1.00 


1.53 


Low autocorrelation binary sequences 


0.44 


1.02 


0.44 


0.45 


Fixed-length error correcting codes 


0.06 


2.26 


0.03 


0.13 


All 


0.52 


3.23 


0.03 


1.86 


All except fixed-length error correcting codes 


0.85 


1.61 


0.44 


1.86 



Table 6: Geometric mean, standard deviation, minimum and maximum of the ra- 
tios between the runtimes of the CaSPER solver implementing the PVlEWS 
model and the Gecode solver implementing the VARS+GLOBAL model, on all 
benchmarks. 

which are orthogonal to the tested models. 

In summary, we have seen how box view objects may be implemented using several 
language paradigms, with a focus on strongly typed languages, namely C++. Decom- 
position models based on auxiliary variables, subtype polymorphic views, and type para- 
metric views were implemented for a number of well known benchmarks, and the results 
were discussed. We observed that type parametric views are clearly more efficient than 
models resulting from the other decomposition/compilation methods for all benchmarks. 
Moreover, we have seen that this technique improves the performance of CaSPER to the 
point of being competitive with Gecode, which is regarded as one of the most efficient 
solvers available. 
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Non-Linear 


P 


t 


f 


u 


calls 


op 


20- 
20- 
10-4- 


Vars 


1.9E+8 


15.7 


651,189 


1.2E+8 


0.0E+0 


1.1E+9 


SViews 


2.4E+7 


8.8 


651,189 


2.0E+7 


1.5E+9 


1.4E+9 


PVlEWS 


2.4E+7 


6.4 


651,189 


2.0E+7 


9.7E+8 


1.4E+9 


S&5- 
20-4- 
3-u 


Vars 


1.6E+8 


19.3 


342,311 


1.0E+8 


0.0E+0 


9.6E+8 


SViews 


1.2E+7 


8.9 


346,762 


1.0E+7 


1.5E+9 


1.6E+9 


PViews 


1.2E+7 


6.5 


346,762 


1.0E+7 


5.2E+8 


1.6E+9 



Table 7: Number of propagator executions (p), seconds (t), fails (f), domain updates 
(u), calls to view object methods (calls), and arithmetic operations (op) when 
solving two instances of the systems of nonlinear equations problem. 

5.3.4 Monitoring Execution 

The theoretical discussion in the previous section hints at the reasons why the view 
models, in particular the PVlEWS model, achieve better performance than the VARS 
model. We checked whether these hints were confirmed in the experiments described 
earlier. To do so, we monitored the execution of many instances of the problems and 
consistently obtained results similar to those reported below. Table 7 shows the results 
obtained with two instances of the problem involving systems of nonlinear equations (see 
5.1.2). First, we note that in the first (satisfiable) instance, the same search trees were 
explored by all models, whereas in the second (unsatisfiable) the VARS model explores a 
slightly smaller tree (1% less failures). As expected, the better performance of both view 
models (about 2 times faster) is due to the lower number of propagator executions as well 
as domain updates (one order of magnitude less than in the VARS model). Moreover, 
PVlEWS improves (20-30 %) on the S VIEWS model because of its better inlining, although 
the compiler is not able to inline all the function calls. 

A similar picture is obtained with three instances of the Golomb problem presented in 
table 8. Again, despite exploring a slightly smaller search space (<1% less failures), the 
performance of the VARS model is penalized (about 33% slow down) by the larger number 
of propagator executions as well as domain updates, both again one order of magnitude 
higher than in the view models. Within these, PVlEWS performs slightly better due to 
function inlining (in this case, there are fewer function calls than the previous example 
even if all function calls were inlined). 
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Golomb 


P 


t 


f 


u 


calls 


op 


10 


Vars 


3.64E+5 


0.05 


1,703 


2.2E+5 





1.9E+6 


SViews 


3.72E+4 


0.04 


1,707 


3.0E+4 


2.3E+5 


1.7E+6 


PVlEWS 


3.72E+4 


0.04 


1,707 


3.0E+4 





1.7E+6 


11 


Vars 


2.06E+6 


0.3 


7,007 


1.3E+6 





1.1E+7 


SViews 


1.84E+5 


0.22 


7,063 


1.5E+5 


1.2E+6 


1.1E+7 


PViews 


1.84E+5 


0.21 


7,063 


1.5E+5 





1.1E+7 


12 


Vars 


1.14E+8 


17.7 


283,156 


6.8E+7 





6.1E+8 


SViews 


9.61E+6 


13.8 


284,301 


8.3E+6 


5.9E+7 


6.6E+8 


PViews 


9.61E+6 


13.4 


284,301 


8.3E+6 





6.6E+8 



Table 8: Number of propagator executions (p), seconds (t), fails (f), domain updates 
(u), calls to view object methods (calls), and arithmetic operations (op) when 
solving three instances of the Golomb problem. 
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6 Conclusion and Future Work 



In this paper we addressed the modeling of decomposable constraints and challenged 
the traditional view that such decomposition is best made through the use of auxiliary 
variables. We showed that the propagation of such decomposable constraints may be 
performed by view based propagators that do not require such auxiliary variables, and 
discussed the properties of several approximations of this approach. In particular, we 
focused on models using box view-based propagators for pragmatic reasons, and showed 
that, notwithstanding the fact that asymptotic worst-case analysis leads to the same 
complexity, when applied to a comprehensive set of benchmarks they perform significantly 
better than those based on auxiliary variables, even when the latter models use stronger 
propagators. 

We have intentionally restricted the instantiation of view models to those consisting 
only of box approximations, largely because box view objects may be implemented ef- 
ficiently. In fact, other view models may be propagated using a similar approach, but 
creating efficient corresponding view objects is much more challenging in general. As an 
example, consider designing a domain view object, that is an object which propagates 
constraints of the form c o /j ■ ■ ■ o f m and computes a ^^-approximation for every image 
and object function of each of the functions /j. Such object must thus be able to compute 
c)-domains, which cannot be done in constant time for most functions fi as it is the case 
for /3-domains. But it will be interesting to check whether this could be done for specific 
classes of functions, similarly to what was done in [26]. 

Finally, given the superior performance of PVlEWS compared with SVlEWS, one may 
question what to do when the former cannot be used directly, as occurs when the problem 
at hand is specified in an interpreted environment such as MiniZinc [21] where there is 
no C++ compilation involved. In this case, an option is to generate C++ code for the 
constraints and compile it with a JIT (Just In Time) C++ compiler. Pre-processing 
constraint problems for generating specific solver binaries is shown in [1]. It would be 
interesting to see if the compilation time would compensate the solving time in our case. 
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